feat: generate initials avatar as default profile image#38638
feat: generate initials avatar as default profile image#38638SantiagoSuHe wants to merge 2 commits into
Conversation
openedx-webhooks
added
open-source-contribution
|
Thanks for the pull request, @SantiagoSuHe! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Update the status of your PRYour PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
When a user has not uploaded a profile photo, generate a personalized JPEG avatar with their initials on a colored circle background instead of returning a generic static placeholder image. Images are generated on first request and cached in storage using a content-addressable key based on username + name. A name change automatically produces a new cache key and a fresh image on the next request. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
SantiagoSuHe
force-pushed
the
feat/initials-avatar-backend
branch
from
8657283 to
0a196f5
Compare
|
|
||
|
|
||
| _AVATAR_COLORS = [ | ||
| '#1565C0', '#2E7D32', '#6A1B9A', '#C62828', '#E65100', |
There was a problem hiding this comment.
update to reference paragon / brand color options - may want to use the paragon label colors here (PR is still a draft so TBD)
There was a problem hiding this comment.
Hi @marcotuts, I've updated the color palette to use values from the Paragon light theme design tokens. The new palette draws from the primary, brand, success, info, and danger color families (two shades per family for variety). I excluded the warning/yellow shades since they don't provide sufficient contrast against white text (WCAG AA).
Here's a preview of the palette: https://coolors.co/palette/0a3055-9d0054-178253-006daa-c32d3a-476480-b6407f-15754b-006299-b02934
Do these colors look good to you, or would you suggest any adjustments?
Use hex values from the Paragon light theme design token system (primary, brand, success, info, and danger families) instead of arbitrary Material Design colors. Warning/yellow shades are excluded because they lack sufficient contrast against white text (WCAG AA). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
How profile avatars work today, and the options for the initials avatarThis is a cleaned-up write-up of how avatars currently work across Open edX and how this PR fits among the alternatives we are considering. It supersedes my earlier update on this thread. How avatars work todayA user's avatar appears in three visible places, and each one obtains it in a different way. 1. The profile page body. It makes a direct call to the accounts API 2. The Discussions section (forums). It makes a single call to fetch the threads/comments, requesting the images of all authors along the way via The response carries every author and their image URL, so it does not make one call per user. It renders each avatar with Paragon's 3. The header (user menu) of the LMS MFEs. This is where the difference lies. The header does not call any API: it reads the URL from a variable it already has in memory,
Since most MFEs do not enable hydration, and the field mapping is also missing, the URL never arrives: the uploaded photo does NOT show in the standard LMS header, even though it does show in the profile and in discussions. (Nuances: the "Learning" header inside a course does not show an avatar by design; the Studio header does show the photo, because it has its own fix in openedx/frontend-component-header#670.) In summary: when a user uploads a photo, it is reflected in their profile and in discussions, but not in the standard LMS MFE header. This is a pre-existing bug, independent of this project. What the project aims forToday, when a user has not uploaded a photo, everyone is shown the same generic gray image (the "fallback"). The project aims to replace that gray image with a personalized avatar: the initial of the username on a colored background, deterministic (the same user always gets the same color), the way Google or Slack do it. If the user uploads a real photo, the photo takes priority. Options to achieve itOption A: Server (this PR). Generate the initials avatar image on the backend and serve its URL just as the user-uploaded photo is served today. In the profile and in discussions the initials avatar appears automatically (those places already read the URL from the server). For the header, you additionally need to (1) enable
Drawback: the server generates and checks the image file on every read (work and storage that do not exist today). Advantage: it also fixes the uploaded-photo bug in the header, because showing that photo requires calling the API (hydrating) anyway. There is an important cost nuance, though:
Option B: Directly in the client's browser. Draw the avatar in each surface where it is used, without generating or requesting any image ("if there is no photo, take the username and draw the avatar in HTML"). The cost is nearly zero, the same as today's gray image. A proof of concept for the header already exists in openedx/frontend-component-header#672. Drawback: the same logic (hash to color, initial) is duplicated across the three surfaces (header, discussions, profile). Option C: Client, via Paragon. Add the initials avatar logic once, inside Paragon's
Advantage: the logic lives in a single place and is themeable. Drawback: the rollout depends on publishing a new version of Paragon and on each consumer bumping the dependency (slower and less controllable). No PR exists for this option yet. cc @edschema @marcotuts @brian-smith-tcril |
4 participants
Summary
Open edX shows a generic static placeholder when a user has not uploaded a profile photo. This PR replaces that placeholder with a personalized avatar: a colored circle with the user's initials, similar to what Google and other platforms do.
A proposal for this feature was posted in the Open edX community forum for visibility: https://discuss.openedx.org/t/profile-avatar-modernization/19046
How it works
The avatar is generated in the backend rather than the frontend so that every consumer of
get_profile_image_urls_for_user()receives it automatically, with no changes needed in individual MFEs or templates. Generating a real JPEG means the image works anywhere profile photos already work, from Django-rendered pages to theedx-user-infocookie, without additional integration.Generation is lazy: nothing happens at account creation. The first time profile image URLs are requested for a user (for example, at login), the system calls
generate_initials_image(username, name). Pillow, already required byopenedx-platformfor resizing uploaded photos, draws a colored JPEG and saves it to storage under a key derived frommd5(username + name). Subsequent requests return the cached file directly. The initials come from the first letter of the user's first and last name, and the background color is deterministically derived from the username using the Paragon light theme design token palette, so the same user always gets the same color. If the user has no name, the first letter of their username is used instead.How the avatar changes over time:
edx-user-infocookie.has_profile_imagebecomesTrueand the uploaded photo is served instead.has_profile_imagegoes back toFalseand the initials avatar is served again.MFE headers require two additional steps outside the scope of this PR. When a MFE loads,
@edx/frontend-platformdecodes the JWT cookie into a basicauthenticatedUserobject that does not include profile image data. To surface the avatar in a MFE header, the MFE must passhydrateAuthenticatedUser: truetoinitialize(), which fetches the full account payload from the accounts API. Additionally, openedx/frontend-platform#885 mapsprofile_image.image_url_fullintoauthenticatedUser.avatarduring hydration. Both conditions are required: hydration without the mapping leaves the avatar field empty, and the mapping without hydration means the API call never happens.Companion PRs
openedx/frontend-app-profileProfileAvatarcomponent to render the URL returned by the backend instead of always showing the SVG placeholder whenhas_imageisfalseopenedx/frontend-platformprofile_image.image_url_fulltoauthenticatedUser.avatarduring hydration so MFE headers receive the avatar URLChanges
openedx/core/djangoapps/profile_images/images.pygenerate_initials_image(username, name)which generates a JPEG avatar for each configured size using Pillowmd5(username + name), generated only once per username/name combinationopenedx/core/djangoapps/user_api/accounts/image_helpers.py_get_default_profile_image_urls()to callgenerate_initials_image()instead of returning static placeholder URLsUserProfile.has_profile_imagesemantics are unchanged -- it remainsFalseuntil the user explicitly uploads a photoTesting
Added tests for
_get_initials(),_get_avatar_color(), andgenerate_initials_image()covering edge cases (empty name, None, whitespace, name change cache invalidation, storage caching behavior).Updated existing tests in
test_image_helpers.pyto mockgenerate_initials_imagefor the default image path.Dependencies
No new dependencies. Pillow is already a required dependency of
openedx-platform.Local MFE Testing
Tested locally against a Tutor dev environment with
frontend-platformPR #885 applied.frontend-app-account— Already hadhydrateAuthenticatedUser: trueupstream. Avatar works.frontend-app-catalog— Does not havehydrateAuthenticatedUser: trueupstream. After adding it, avatar works.frontend-app-gradebook— Does not havehydrateAuthenticatedUser: trueupstream. After adding it, avatar works.frontend-app-learner-dashboard— Does not havehydrateAuthenticatedUser: trueupstream. After adding it, avatar works.frontend-app-learner-record— Does not havehydrateAuthenticatedUser: trueupstream. After adding it, avatar works.frontend-app-admin-console— Does not havehydrateAuthenticatedUser: trueupstream. After adding it, avatar appears but renders at 500×500px — the Studio header renders<img>directly inside the button when a URL is set, bypassing Paragon's<Avatar>component which constrains the size. Needs a fix inopenedx/frontend-component-header.frontend-app-authoring— Does not havehydrateAuthenticatedUser: trueupstream. After adding it, same Studio header size bug as admin-console.frontend-app-admin-portal— Not testable locally (requires enterprise context).frontend-app-learner-portal-enterprise— Not testable locally (requires enterprise microservices).frontend-app-discussions— Not testable locally (forum service not included in the standard Tutor dev stack).